Only marked as draft because it requires a baseline which is not yet in main - will rebase once next baseline is settled.

CCB 2020-12-09 APPROVED

• Do we expect other platforms to support the condition variables from posix? There are "barriers" in RTEMS but they're not paired with mutex. VxWorks has binary semaphores but also suffers from the non atomic issue. These have a risk that the state can change in the midst of the call.
• RTEMS does have a posix layer that might include the needed functionality
• Caution against having a difference platform implementation for a minor performance gain
• Concerns that the polling and delay would result in taking more time for this operation than expected
• @jphickey open issue about this in VxWorks and RTEMS

Rebased to main.

Also fixed an intermittent issue I found in testing where the mutex would not be released. There is a test case where a task gets deleted immediately after creation, and sometimes this would happen while it was still initializing and holding the table mutex. Solution is to add a cleanup handler around the pthread_cond_wait just like bin sems use, so if the task is deleted, the mutex also gets unlocked.

@jphickey I resolved a small conflict here, I'll do a squash-commit on this unless you want to rebase and force push.

@jphickey I resolved a small conflict here, I'll do a squash-commit on this unless you want to rebase and force push.

Yes, I recall a small conflict with the #endif comment.

Does it really need a rebase though? Can't we just make a normal merge commit with the conflict resolved? Do you want me to do that in the integration candidate?

I don't like squashes at this point because it makes it hard to track what branches in my fork can be deleted (i.e. there is no specific git record of the merge, and git branch --merged doesn't report it, and so on).

@jphickey I resolved a small conflict here, I'll do a squash-commit on this unless you want to rebase and force push.

Yes, I recall a small conflict with the #endif comment.

Does it really need a rebase though? Can't we just make a normal merge commit with the conflict resolved? Do you want me to do that in the integration candidate?

I don't like squashes at this point because it makes it hard to track what branches in my fork can be deleted (i.e. there is no specific git record of the merge, and git branch --merged doesn't report it, and so on).

I suggested a rebase to avoid having f5b84da in the commit history.

Regarding the squash, I think github gives me the option to delete the branch after merging

No worries about f5b84da we can avoid this either way.

Regarding deleting branches I also need to delete them on my local machine - not just the fork. I very much prefer not to break git branch --merged command.

I can easily/quickly push a merge commit to integration-candidate that fixes it. Or alternatively if you really prefer a rebase I can do that too but I'd prefer to do it myself as it keeps my local branches in sync with my fork branches.